Web services is a key on demand technology and is a standard way to interact with remote services. Technology exists to enable clients to invoke remote services as if they were local services. Furthermore, applications can implement web services as easily as writing routines for normal Java methods.
However, there is a problem with the prior art policy of allowing (1) which remote service to use and (2) when to use it, being determined by a client. In addition, applications must conform to the service activation model of the web service hosting application to implement web services. These hosting applications bring with them their own management and configuration issues as well as a large footprint.
OSGi
Open Service Gateway Initiative (hereinafter “OSGi”) (Please see http://www.osgi.org and OSGi: OSGi Service Platform. Release 3. IOS Press, (March 2003.) is a framework that allows applications to be decoupled from the services they use. Policy decisions of which services are made available and when they are made available can be done outside of the application. OSGi provides a Java platform, JAX-RPC (Please see Java™ API for XML-based Remote Procedure Call (JAX-RPC) Specification, version 1.1: Maintenance Release, JSR 101, (October 2003).), for managing functional units, called bundles, that can be dynamically added and removed at runtime. The platform also manages interaction between bundles using a service registry that enables a bundle to explicitly register objects to be shared with other bundles. Together, the bundle management and service registry provide a powerful environment for managing the interaction of bundles and services. The goal of OSGi is to “create open specifications for the network delivery of managed services to local networks and devices.”
Prior art FIG. 1 shows an example of two bundles 110 and 112 interacting through a services registry 120. In the example, bundle 110 is a bundle that registers a service, svc, 130, via a registration 140. The service will be registered under one of the interfaces it implements and, optionally, additional properties that describe service 130.
Once service 130 has been registered, bundle 112 can query service registry 120 to find service 130 via a query, or a lookup, 142. Service registry 120 will return a reference to service 130, via a return 144. Therefore, bundle 112 can invoke methods on service 130, via an invoke 146, just as it can invoke methods on any other object.
Bundles
Functionality is added to an OSGi framework in the form of bundles, such as bundles 110 and 112. A bundle is a collection, usually in the form of a JAR file, of classes and resources. A bundle is started by instantiating an activator class, specified in the bundle's manifest, and invoking a start( )method on the instantiated object.
In theory a bundle may have all the classes it needs to run. In other words, OSGi does provide a way to import all shared classes. However, in practice, a bundle will need to share objects with another bundle. When this sharing is done, the two bundles will need a shared class so that they can both interact with the shared object without getting a ClassCastException.
In order to enable class sharing, bundles explicitly define which packages they export (share) and import (use) in their manifest. The framework ensures that the imports and exports are resolved correctly. If the exporter of a package changes, perhaps because it was updated or uninstalled, any importers will be re-resolved and thus restarted or stopped if no exporters remain.
Once a bundle as been started it may provide some functionality directly to a user or device using its own classes, it may need services provided by another bundle, or it may just provide services to other bundles.
Bundles can use in web service runtime (a) either web service stubs (b) or dynamic invocation interfaces. However, the OSGi service registry, such as service registry 120, provides a decoupling of the services being used from the users of the service. Service registry 120 provides a way to change the web service used by a bundle, such as bundle 112, without changing a bundle's code or its configuration. It allows a bundle, such as bundle 112, to use a local implementation of the web service, such as web service 235, without any code changes even if it was written to use a web service through service registry 120.
OSGi Service
An OSGi service is an object that is registered by a bundle providing the service in a service registry. In general an OSGi service is registered using the name of an interface implemented by the object and a list of properties describing the service. This allows a clean decoupling of the interfaces used by bundles in their interaction from the implementation of those interfaces.
Service Registry
The OSGi platform also provides a service registry, such as service registry 120, to allow components to interact through defined objects, which is another feature missing from Java. Bundles can find registered services by querying the service registry. If a bundle has registered a service listener with the framework, the bundle will also be notified when services get added to or removed from the service registry.
Stopping a Bundle
When a bundle is stopped, the framework will invoke the stop( )method on the activator object, unregister any services the bundle has registered, and release any services being used.
Permissions
OSGi also uses Java permissions. Each bundle is assigned a set of permissions. These permissions are checked by the OSGi framework when it interacts with the service registry. Bundles also use permission checks when providing services to other bundles.
Security in OSGi
OSGi provides authentication security via a UserManager service. UserManager service is a standard service in OSGi that maps a user id in to the groups that user belongs to and a set of public and private information.
OSGi provides authorization security by using Java permissions to authorize requests made by bundles. The framework uses a ServicePermission to restrict which bundles can access a service, and the services themselves have service specific permissions to restrict what other bundles can do.
Pluggable Functionality
The OSGi platform enables the dynamic management of pluggable functionality, a feature that has been highly touted but not fully realized by Java (e.g. of Sun Microsystems, Inc.). in general. Pluggable functionality is implemented using Java components that can be updated and removed at runtime without restarting the JVM.
Problems with OSGi
OSGi has certain problems. For example, OSGi only handles local services which are services running in the same runtime. Specifically, OSGi only addresses the interaction of services running locally, inside the platform and does not address the interaction of services running between platforms. In other words, OSGi does nothing to provide access to services that are provided by components outside of the Java runtime. In addition, using OSGi to register all services from a single bundle leads to the problem of if any of the imported packages became unresolved, then (1) the bundle would stop and (2) all proxies would be unregistered.
Web Services
On the other hand, web services specifically addresses how remote services interact. Web services is emerging as a standard way to provide services that can be invoked by remote clients. The standards are being set up to allow various platforms and applications written in diverse languages to interact.
JAX-RPC
For example, the Java JAX-RPC specification (hereinafter “JAX-RPC”) already provides a mapping between web services and the Java platform. Specifically, the JAX-RPC specification defines a standard way of using web services. This mapping allows a Java client to use web services without worrying about which platform that service is implemented on or which language the service is written in. In other words, in Java, each web service is represented by an interface. A type of JAX-RPC is an embedded version of JAX-RPC called JSR172 (Please see http://www.jcp.org/aboutJava/communityprocess/review/jsr172/.)
Implementations of JAX-RPC provide the ability to create classes from WSDL that will (a) implement the interface defined by the web service and (b) do the necessary work to communicate with the server providing the web service. This proxying can even be done dynamically by creating the object that implements the interface at run time.
Type of Web Services
The term web services is used very loosely. In a context, web services mean web services that are compliant with JAX-RPC, a mapping of Java interfaces to Web Service Description Language (WSDL) (Please see Web Services Description Language (WSDL) 1.1: W3C Note (15 Mar. 2001) at http://www.w3.org/TR/wsdl.html.) and its corresponding Simple Object Access Protocol (SOAP) (Please see E. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP) 1.1. (May 2000) at http://www.w3.org/TR/SOAP.) messaging. In short, JAX-RPC is a standard way of invoking web services using Java interfaces. It defines standards for mapping primitive classes to standard web service types. It also defines the serialization of non primitive types.
WSDL File
The definition of a web service is given by a WSDL file. This file contains the definition of non-primitive classes used by the service, the interface and methods provided by the service, and the Uniform Resource Locater (URL) to be used to invoke the service.
Problems with Web Services
Web services have several problems.
Limitations in JAX-RPC
For example, web services suffer from limitations in JAX-RPC. Specifically, JAX-RPC is limited in the types of interfaces that can be mapped to JAX-RPC. For example, with JAX-RPC, remote references are not allowed such that an object that is passed to or returned from a method must be serializable. In other words, objects that are used for callbacks or have methods that cannot be evaluated locally, such as InputStream.read( ), cannot be used.
In addition, with JAX-RPC, complex types must be “bean like” such that all objects sent and returned must be able to be queried to get the values needed for serialization. “Bean like” means a complex type has a default constructor and standard ways of setting and getting its members. Further, when a method returns, the returned values must be able to be instantiated.
Imperfect Mappings
In addition, web services suffer from imperfect mappings. For example, the mapping of WSDL to Java classes is not a perfect 1:1 mapping. The JAX-RPC specification doesn't have a standard way of mapping WSDL names to Java packages. Specifically, the recommendation in JAX-RPC maps an unlimited number of WSDL names to the same package. In other words, there is not a 1:1 mapping between Java classes and WSDL.
Different Implementations of Complex Types
In addition, complex types can also have many different implementations in Java, where different implementations may not be compatible.
Therefore, a method and system of mapping at least one web service to at least one OSGi service and exposing at least one local service as at least one web service is needed.